Summary

A BigDecimal constructed from extreme scientific notation (e.g. new BigDecimal("1e1000000000")) has scale = -1_000_000_000. Calling toPlainString() on such a value materializes a plain-decimal string of ~1 × 10⁹ characters (~2 GB), exhausting the JDBC client JVM heap and causing a denial of service.

This path is reachable from user-controlled input via:

IoTDBPreparedStatement.setObject(idx, maliciousBigDecimal, Types.VARCHAR);

which routes through StringUtils.consistentToString(BigDecimal) → reflective BigDecimal.toPlainString().

Reproducer (before the fix)

BigDecimal d = new BigDecimal("1e1000000000");
StringUtils.consistentToString(d); // → OutOfMemoryError

Observed on JDK 8, -Xmx512m:

Note: because InvocationTargetException also wraps OutOfMemoryError, the existing catch block can silently swallow the OOM on small-heap clients and fall back to toString(). On larger heaps the allocation succeeds and the client process is OOM-killed. Both behaviors are undesirable.

Fix

Add a scale guard in StringUtils.consistentToString(BigDecimal). When |scale| > 10_000, fall back to BigDecimal.toString() (compact scientific form) instead of invoking toPlainString(). The threshold is orders of magnitude above any realistic decimal precision and is therefore transparent to legitimate data (a 10 000-char plain string is only ~10 KB).

if (decimal.scale() > MAX_PLAIN_STRING_SCALE
    || decimal.scale() < -MAX_PLAIN_STRING_SCALE) {
    return decimal.toString();
}

Also tightens the reflective invocation: toPlainStringMethod.invoke(decimal, (Object[]) null) to remove the varargs-null ambiguity warning.

Why fix it here (and not in IoTDBPreparedStatement)

StringUtils.consistentToString is the only caller of BigDecimal.toPlainString() in the JDBC driver. Fixing it at the root closes every existing and future call site with a single change, rather than duplicating the check in setObject for CHAR/VARCHAR/LONGVARCHAR.

Tests

Added StringUtilsTest covering:

• null input
• Normal decimal (123.45 and 1E+2 → "100")
• Boundary case at MAX_PLAIN_STRING_SCALE (still expanded to plain form)
• Regression for the PoC payload 1e1000000000 (must return compact scientific form, not a 1 GB string)
• Symmetric case for huge positive scale (1e-1000000000)

All 5 tests pass.

Risk / compatibility

• No API changes.
• Behavior only differs for pathological values whose plain string would exceed ~10 KB — these inputs previously produced either an OOM (swallowed) or a multi-GB string and could not have been relied on.
• Normal decimal data is bit-for-bit identical to before.

Credits

Vulnerability reported by:
Ho1aAs, movonow, zhid889773, WA-888, binghuangczc, errors11, Phoexina, skydiver-jay, V9d0g, FlyFish.